The CDPD Public Domain Collection for CDTV 4/CDPD_IV.bin/e/mailinglists/amigae.0793july.archive/000012_crash!mars.let.uva.nl!wouter_Wed, 7 Jul 93 21:58:39 PST.msg

Internet Message Format | 1994-05-26 | 6KB

Received: by bkhouse.cts.com (V1.16/Amiga)
    id AA00000; Wed, 7 Jul 93 21:58:39 PST
Received: from mars.let.uva.nl by crash.cts.com with smtp
    (Smail3.1.28.1 #15) id m0oDliv-00009vC; Wed, 7 Jul 93 19:28 PDT
Received: by mars.let.uva.nl id AA28485
  (5.65c/IDA-1.4.4 for [e-mail]); Thu, 8 Jul 1993 04:32:05 +0200
Return-Path: <[e-mail]>
Date: Thu, 8 Jul 1993 04:32:05 +0200
Message-Id: <[e-mail]>
X-Organisation: Department of Computational Linguistics,
                University of Amsterdam
                Spuistraat 134, 1012 VB Amsterdam, The Netherlands
From: Wouter van Oortmerssen <[e-mail]>
To: [e-mail]
Subject: about improvement suggestions

>>   I don't know how (or if) I could become a Beta-tester for Wouter, but if I
>> did I might make the following suggestions:
>>
>> 1) I've tried to write a couple of utilities recently, and I've needed to be
>>    able to write a PROC which takes its arguments in certain registers (a
>>    PROC suitable for SetFunction()ing).  I could probably write it in inline
>>    assembly but I'd much rather not.  Would it be easy to add this feature to
>>    PROC definitions (like 'C')?

see #4

>> 2) Also, a simple E command to preserve/reinstate the registers would be hand

>>    Someone will probably suggest a MOVEM command but am I allowed to rely on

>>    the stack being in certain states?

before or after a piece of inline assembly you may safely use a movem
to save registers. (this is really only needed for a4/a5).
I don't think a special command for this is needed.

>> 3) What about a few options to make a compiled E program detach itself and ru

>>    in the background? (You can use 'runback' utilities but its not ideal.)

I have this on my "TODO" list.

>>    Would it be possible to add support for (checking?) the purity of code? (S

>>    you know if you can make it a 'resident' program, or even something like
>>    a handler or library.)

executables as produced by EC are PURE. one of the only things I can
think of that could make it "unpure" are lists with anything other than
constant values in them, like [a,b+1,fun()]

>> 4) On the subject of handlers, is it possible to write one purely in E? (No
>>    assembly used?)  If so, that would make a really nice example to give away
>>    in the package (documentation is *so* lacking in CBM's books).  Maybe
>>    someone could translate Matt Dillon's ram: handler...

these features all boil down to low-level support for own libraries,
devices and handlers, new tasks, hooks etc. I'm working on making some
of this possible in 2.5, the registers might have to wait till later,
simply because there are nicer things higher up my list :-)

>> 5) I'm gald to hear a debugger is on its way.  That was going to be my fifth
>>    suggestion!

don't know yet in what form, but it's heavily needed. probably something
very unorthodox like a runtime source-level debugger

>> 6) What E really needs, though, to make it great is some great documentation

agreed.

>>    E can really be the beginners language because it's very much like Pascal

I disagree. Don't let syntax deceive you. Ok, that makes it all very
readable but:
- when it comes to semantics (workings/meanings of programming constructs),
  E is much closer to C/C++ than to Pascal/Modula2
- once you know E, it lets you implement ideas much faster than in traditional
  languages, which would give the impression that E is appropriate for
  beginners, but E's low-level nature and type-system require a quite
  serious knowledge of pointers etc., which could frustrate the beginner.
  A language suited for beginners would either make dangerous use of
  pointers impossible (like Pascal) or don't provide such features at all.

>>    or Modula-2, and it compiles **SOOOO**** quickly compared to  most other
>>    languages.  I am willing to help write such documentation if Wouter would

I already have somebody that wants to write a decent manual/tutorial,
but if you feel you have concrete ideas of how you could help out,
mail me.

>>    like this.  The only thing stopping me helping now is I don't yet feel I
>>    know enough about the language.
>>
>> 7) Marketing E as a commercial product should be easy (E-zee!).  Get the majo

>>    Amiga mags interested (in the UK at least...) and people should be beating
>>    a path to your door, Wouter!

um, maybe. I had almost finally decided to bring out 2.5 myself just
to be independend of a company's demands, and to keep the price low,
but I've decide to maybe give some serious company a chance.
suggestions anyone?

>> Finally, I am extremely impressed with E.  I am even more impressed with the
>> support which Wouter has been giving.  This language has great possibilities!
>> It's not the perfect large application development language yet, but it sure
>> seems like it will be soon.

count on it. with 2.1 you were flabbergasted at it's compile speed, now
with 2.5 get knocked out of your socks at the speed it links large
multi-module apps together.

>> SAS, Aztec and the others had better watch out.

don't make yourself any illusions. C is so deep rooted everywhere that
it (and it's descendants like C++) will be used heavily for a long time
(which doesn't mean of course we can't be making life better with
alternatives like E!)

>> Thanks, Wouter, for a brilliant piece of programming.

anytime!

>> ----
>>    _____  _
>>      /   / |    /  /
>>     /   /__/   /__/      Jason R. Hulance
>>    /   /\     /  /   <[e-mail]>
>> |_/ . /  \ . /  / .
>>

Wouter

   ____  Wouter van Oortmerssen, [e-mail]
  / __/  "Einen Satz verstehen, heisst, wissen was der Fall ist,
 / __/    wenn er wahr ist" - Wittgenstein
/___/  ->subscribe to the E mailing list: [e-mail]<-